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FOREWORD 


The  Department  of  Defense  (DoD)  High  Level  Architecture  (HLA)  has  been  designed  to 
facilitate  interoperability  among  simulations  and  to  promote  reuse  of  simulations  and  their 
components.  The  HLA  is  composed  of  three  major  components: 

•  HLA  Rules'.  A  set  of  ten  basic  rules  that  together  describe  the  general  principles  defining 
the  HLA. 

•  HLA  Interface  Specification:  A  description  of  the  functional  interface  between 
simulations  (federates)  and  the  HLA  Runtime  Infrastructure  (RTI). 

•  HLA  Object  Model  Template  (OMT):  A  specification  of  the  common  format  and  structure 
for  documenting  HLA  object  models. 

In  an  HLA  application,  any  number  of  physically  distributed  simulation  systems  can  be 
brought  together  into  a  unified  simulation  environment  to  address  the  needs  of  new  applications. 
These  types  of  environments  are  known  as  HLA  federations .  The  HLA  specifications  together 
define  an  overarching  framework  for  the  construction  and  execution  of  federations. 

Within  the  DoD  and  other  government  and  commercial  organizations,  many  different 
approaches  to  project  management  and  systems  engineering  are  being  used.  Such  practices, 
procedures,  and  methodologies  have  evolved  over  time  based  on  how  well  they  serve  the 
different  functional  areas  and  user  communities  for  which  they  are  intended.  Many  of  these 
approaches  currently  use  modeling  and  simulation  (M&S)  as  a  key  enabler  of  certain  functions, 
such  as  concept  evaluation,  testing,  and  training.  However,  few  application  areas  have  yet 
determined  how  to  tailor  their  native  management  and  engineering  processes  to  take  advantage  of 
HLA.  For  instance,  while  many  in  the  analysis  community  have  established  procedures  for  non¬ 
runtime  exchange  of  data  from  one  simulation  to  another,  the  opportunities  provided  by  HLA  for 
more  dynamic  exchange  of  data  at  runtime  requires  that  existing  engineering  processes  be 
modified  or  augmented  in  order  to  take  advantage  of  such  opportunities.  Even  in  communities  in 
which  distributed  simulation  is  more  commonplace  (e.g.,  training),  migration  to  HLA  generally 
requires  some  modification  to  existing  management  and  engineering  processes  to  capture  the 
benefits  offered  by  HLA.  As  simulation  users  begin  this  migration,  it  is  critical  that  guidance  be 
available  to  orient  new  users  to  the  specific  set  of  tasks  and  activities  necessary  to  develop  HLA 
federations. 
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This  document  describes  the  HLA  Federation  Development  and  Execution  Process 
(FEDEP)  Model.  The  purpose  of  this  document  is  to  describe  a  generalized  process  for  building 
HEA  federations.  It  is  not  intended  to  replace  the  existing  management  and  engineering 
processes  of  HEA  user  organizations,  but  rather  to  provide  a  high-level  framework  for  HEA 
federation  construction  into  which  lower-level  development  practices  native  to  each  individual 
application  area  can  be  easily  integrated.  In  addition,  the  HEA  EEDEP  is  not  intended  to  be 
prescriptive,  in  that  it  does  not  specify  a  “one  size  fits  all”  federation  development  process  for  all 
HEA  users.  Rather,  the  EEDEP  defines  a  generic,  common  sense  systems  engineering 
methodology  for  HEA  federations  that  can  and  should  be  tailored  to  meet  the  needs  of  individual 
applications. 

Although  every  HEA  application  requires  a  basic  agreement  among  all  federates  as  to  the 
systems  engineering  approach  that  will  be  used  to  develop  the  federation,  there  can  be  significant 
variability  in  the  degree  of  formality  defined  in  the  chosen  process.  The  primary  driver  for  how 
much  formality  is  required  is  the  size  and  complexity  of  the  application.  For  example,  in  large 
complex  applications  with  many  distributed  federates,  project  control  requirements  generally 
dictate  the  need  for  a  rigidly  defined,  highly  structured  federation  development  process  to  ensure 
proper  communication  and  coordination  among  all  team  members.  In  such  federations, 
requirements  and  associated  schedules  for  delivery  of  federation  products  are  generally  very 
explicit,  as  is  the  content  and  format  for  documentation  of  these  products.  In  smaller  or  less 
complex  applications,  a  less  structured  process  with  fewer  constraints  on  the  types,  formats,  and 
content  of  federation  products  may  be  perfectly  reasonable  and  may  have  certain  efficiency 
advantages  as  compared  to  a  more  formalized  process. 

Other  secondary  factors  may  also  drive  the  federation  development  process  selected  for  a 
specific  application.  For  instance,  some  communities  may  have  documentation  requirements  that 
are  unique  to  their  application  area.  In  this  case,  the  federation  development  activities  required  to 
produce  these  products  must  be  accounted  for  in  the  overall  process.  The  reuse  potential  of  these 
and  other  required  federation  products  may  also  influence  the  nature  and  formality  of  the 
activities  that  produce  them.  Another  factor  is  the  availability  of  reusable  federation  products 
and  persistent  federation  development  teams,  as  opportunities  for  shortcuts  and  thus  a  more 
streamlined,  efficient  development  process  may  be  identified  and  taken  advantage  of.  Finally, 
practical  resource  constraints  (i.e.,  cost,  schedule)  may  dictate  how  certain  federation 
development  activities  are  performed  and  how  the  associated  federation  products  are  produced 
and  documented. 

In  summary,  it  is  recognized  that  the  needs  and  requirements  of  the  distributed  simulation 
community  are  quite  diverse.  The  HEA  provides  a  generalized  architecture  for  simulation 
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interoperability;  however,  striet  adherenee  to  the  HLA  speeifieations  is  not,  by  itself,  suffieient  to 
ensure  a  fully  eonsistent,  interoperable  distributed  simulation  environment.  For  instance,  issues 
such  as  the  need  for  consistent  environmental  databases  and  for  consistent  behavior 
representations  of  objects  modeled  by  more  than  one  federate  are  critical  to  achieving 
interoperability;  however,  these  types  of  issues  cannot  be  fully  addressed  solely  through 
adherence  to  the  HLA  specifications.  Although  some  technical  or  managerial  issues  may  be 
unique  to  a  given  application,  many  other  issues  associated  with  building  a  fully  interoperable 
HLA  federation  are  more  general  in  nature.  The  HLA  FEDEP,  in  conjunction  with  the  EEDEP 
Checklists  (separate  document),  are  offered  to  the  HEA  community  as  a  starting  framework  for 
identifying  and  addressing  these  more  general  issues,  as  discussed  within  the  context  of  a  full 
end-to-end  process  model  for  the  development  of  distributed  simulation  environments 
(federations)  that  fully  conform  with  the  HEA  specifications.  This  framework  can  and  should  be 
tailored  as  appropriate  to  address  the  unique  issues,  requirements,  and  practical  constraints  of 
each  individual  application.  It  is  expected  that  this  framework  will  provide  a  viable  foundation 
for  all  HEA  applications  and  will  assist  the  users  in  defining  the  specific  tasks  and  activities 
necessary  to  support  their  particular  needs. 
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RELATED  DOCUMENTS 


The  three  specifications  that  together  compose  the  HLA  provide  the  technical  foundation 
for  designing  and  developing  all  HLA  federations.  These  specifications  are  described  in  the 
following  documents: 

•  HLA  Rules  V1.3 

•  HLA  Interface  Specification  V1.3 

•  HLA  Object  Model  Template  V1.3 

Each  of  these  three  documents  can  be  accessed  via  the  HLA  home  page  at 
http://hla.dmso.mil/tech/.  In  addition,  a  more  detailed  description  of  the  lower-level  technical 
issues  that  must  be  considered  and  resolved  throughout  an  HLA  federation  development  can  be 
found  in  a  companion  document  to  the  FEDEP  called  the  FEDEP  Checklists.  This  document, 
along  with  other  relevant  federation  development  resources,  may  be  accessed  at 
http://hla.dmso.mil/federation/. 
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1.  PURPOSE 


The  Department  of  Defense  (DoD)  Modeling  and  Simulation  Master  Plan  [DOD95]  calls 
for  the  establishment  of  a  DoD-wide  High  Eevel  Architecture  (HEA)  for  modeling  and 
simulation  (M&S)  applicable  to  a  wide  range  of  functional  applications.  The  purpose  of  this 
architecture  is  to  facilitate  interoperability  among  simulations  and  promote  reuse  of  simulations 
and  their  components. 

A  named  set  of  simulations  interacting  via  the  services  of  the  HEA  Runtime 
Infrastructure  (RTI)  and  in  accordance  with  a  common  object  model  and  a  common  HEA  rule  set 
is  known  as  an  HLA  federation.  The  purpose  of  this  document  is  to  describe  a  high-level  process 
by  which  HEA  federations  can  be  developed  and  executed  to  meet  the  needs  of  a  federation  user 
or  sponsor.  It  is  expected  that  the  guidelines  provided  in  this  document  are  generally  relevant  to 
and  can  facilitate  the  development  of  most  HEA  federations. 
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2.  FEDEP  MODEL:  TOP-LEVEL  VIEW 


One  of  the  design  goals  identified  early  in  the  development  of  the  HEA  was  the  need  for  a 
high  degree  of  flexibility  in  the  process  by  which  HEA  applications  could  be  composed  to 
achieve  the  objectives  of  particular  applications.  Because  of  this  basic  desire  to  avoid  mandating 
unnecessary  constraints  on  how  HEA  applications  are  constructed,  it  was  recognized  that  the 
actual  process  used  to  develop  and  execute  HEA  federations  could  vary  significantly  within  or 
across  different  user  applications.  Eor  instance,  the  types  and  sequence  of  low-level  activities 
required  to  develop  analysis-oriented  federations  is  likely  to  be  quite  different  from  those 
required  to  develop  distributed  training  exercises.  However,  at  a  more  abstract  level,  it  is 
possible  to  identify  a  sequence  of  six  very  basic  steps  that  all  HEA  federations  will  need  to 
follow  to  develop  and  execute  their  federations.  Eigure  2-1  illustrates  each  of  these  steps  (along 
with  major  inputs/outputs)  and  is  summarized  below: 

•  Step  1:  Define  Federation  Objectives.  The  federation  user  and  federation  development  team 
define  and  agree  on  a  set  of  objectives  and  document  what  must  be  accomplished  to  achieve 
those  objectives. 

•  Step  2:  Develop  Federation  Conceptual  Model.  Based  on  the  characteristics  of  the  problem 
space,  an  appropriate  representation  of  the  real  world  domain  is  developed. 

•  Step  3:  Design  Federation.  Eederation  participants  (federates)  are  determined,  and  required 
functionalities  are  allocated  to  the  federates. 

•  Step  4:  Develop  Federation.  The  Eederation  Object  Model  (EOM)  is  developed,  federate 
agreements  on  consistent  databases/algorithms  are  established,  and  modifications  to  federates 
are  implemented  (as  required). 

•  Step  5:  Integrate  and  Test  Federation.  All  necessary  federation  implementation  activities  are 
performed,  and  testing  is  conducted  to  ensure  that  interoperability  requirements  are  being 
met. 

•  Step  6:  Execute  Federation  and  Prepare  Results.  The  federation  is  executed,  outputs  are 
generated,  and  results  are  provided. 
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Figure  2-1.  Six-Step  Process 

Since  this  six-step  process  can  be  implemented  in  many  different  ways  depending  on  the 
nature  of  the  application,  it  follows  that  the  time  and  effort  required  to  build  an  HEA  federation 
can  also  vary  significantly.  Eor  instance,  it  may  take  a  federation  development  team  several 
weeks  to  fully  define  the  real  world  domain  of  interest  for  very  large,  complex  applications.  In 
smaller,  relatively  simple  applications,  the  same  activity  could  potentially  be  conducted  in  a  day 
or  less.  Differences  in  the  degree  of  formality  desired  in  the  development  process  can  also  lead 
to  varying  requirements  for  federation  resources. 

Personnel  requirements  can  also  vary  greatly  depending  on  the  scope  of  the  federation 
application.  In  some  situations,  highly  integrated  teams  composed  of  several  individuals  may  be 
needed  to  perform  a  single  role  in  a  large,  complex  federation,  while  a  single  individual  may 
perform  multiple  roles  in  smaller  applications.  Examples  of  the  types  of  roles  individuals  can 
assume  in  HEA  federations  include  the  federation  user/sponsor,  the  federation  manager, 
technologists,  security  analysts,  verification,  validation,  and  accreditation  (VV&A)  analysts, 
functional  area  experts,  federation  designers,  execution  planners,  federation  integrators, 
federation  operators,  federate  representatives,  and  data  analysts.  Some  roles  (e.g.,  operators)  are 
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unique  to  a  single  activity  in  the  federation  development  process,  while  others  are  more  pervasive 
throughout  the  process  (e.g.,  federation  manager).  Since  the  applicability  of  a  given  role  (as  well 
as  the  set  of  activities  it  spans)  varies  from  application  to  application,  the  activities  described  in 
this  document  specify  the  roles  of  individuals  only  in  generic  terms. 

A  major  source  of  variation  in  how  the  six-step  process  is  implemented  relates  to  the 
degree  of  reuse  of  existing  federation  products.  In  some  cases,  federations  may  be  developed 
largely  from  scratch,  using  a  newly  defined  set  of  requirements  to  identify  an  appropriate  set  of 
federates  and  to  build  the  full  set  of  federation  products  needed  to  support  an  execution.  In  other 
cases,  users  of  federations  will  have  more  long-standing  requirements  and  will  cumulatively 
apply  their  developmental  activities  for  each  new  application.  In  these  situations,  federation 
developers  can  often  meet  new  user  requirements  by  reusing  a  subset  of  an  established  core  set  of 
federates  and  defining  appropriate  modifications  to  other  reusable  federation  products  within 
their  domain  (e.g.,  EOM,  planning  documents,  Eederation  Execution  Planning  Workbook 
[EEPW]).  When  an  appropriate  management  structure  exists  to  facilitate  this  type  of  federation 
development  environment,  significant  savings  can  be  achieved  in  both  cost  and  development 
time. 

The  remainder  of  this  document  describes  a  structured,  systems  engineering  approach  to 
federation  development  known  as  the  HEA  Eederation  Development  and  Execution  Process 
(EEDEP).  The  six-step  process  provides  a  top-level  view  of  the  EEDEP,  while  the  EEDEP  itself 
describes  a  decomposition  of  each  of  the  six  major  steps  into  a  set  of  interrelated  lower-level 
activities  and  supporting  information  resources.  Since,  at  this  time,  the  needs  of  the  HEA  user 
community  are  focused  primarily  on  “first  use”  applications,  the  EEDEP  currently  makes  no 
assumptions  about  the  existence  of  an  established  core  set  of  federates  or  the  up-front  availability 
of  reusable  federation  products.  Although  the  intention  is  to  define  a  comprehensive,  generalized 
framework  for  HEA  federation  construction,  it  is  important  to  recognize  that  users  of  this  process 
model  will  normally  need  to  adjust  and  modify  the  EEDEP  as  appropriate  to  address  the  unique 
requirements  and  constraints  of  their  particular  application  area. 
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3.  FEDEP  MODEL:  DETAILED  VIEW 


The  EEDEP  Model  describes  a  high-level  framework  for  the  development  and  execution 
of  HEA  federations.  The  intent  of  the  EEDEP  Model  is  to  specify  a  set  of  guidelines  for 
federation  development  and  execution  that  federation  developers  can  leverage  to  achieve  the 
needs  of  their  application. 

The  structure  of  the  EEDEP  Model  is  illustrated  in  Eigure  3-1.  Data  Elow  Diagram 
(DED)  notation  is  used  in  Eigure  3-1  and  throughout  this  document  to  represent  federation 
development  activities  (rounded  rectangles),  data  stores  (cylinders),  and  information  flows 
(arrows)  [SIW98].  The  federation  development  activities  shown  in  this  diagram  are  organized 
into  six  vertically  aligned  groupings,  each  representing  a  first- level  decomposition  of  one  of  the 
six  major  federation  development  steps.  A  mapping  of  EEDEP  activities  to  the  six-step  process 
is  also  provided  in  Table  3-1. 

The  following  subsections  describe  the  lower-level  activities  associated  with  each  of  the 
six  major  federation  development  steps  and  how  these  activities  interrelate.  Although  many  of 
the  activities  represented  in  the  EEDEP  diagram  appear  highly  sequential,  the  intention  is  not  to 
suggest  a  strict  waterfall  approach  to  federation  development.  Rather,  this  process  illustration  is 
simply  intended  to  highlight  the  major  activities  that  occur  during  federation  development  and 
approximately  when  such  activities  are  first  initiated  relative  to  other  federation  development 
activities.  In  fact,  experience  has  shown  that  many  of  the  activities  shown  in  Eigure  3-1  as 
sequential  are  actually  cyclic  and/or  concurrent,  as  was  indicated  earlier  in  Eigure  2-1  via  the 
dotted  feedback  arrows.  Users  of  the  EEDEP  should  be  aware  that  the  activities  described  in  this 
document,  while  being  generally  applicable  to  most  HEA  federations,  are  intended  to  be  tailored 
to  meet  the  needs  of  each  individual  application.  Eor  example,  EEDEP  users  should  not  feel 
constrained  by  the  federation  products  explicitly  identified  in  this  document,  but  rather  should 
produce  whatever  additional  documentation  is  necessary  to  support  their  application.  Eederation 
developers  should  generally  expect  to  use  and  leverage  the  EEDEP  view  as  a  starting  point  for 
whatever  specific  approach  to  federation  development  is  deemed  most  appropriate  for  their 
application. 
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Figure  3-1.  Federation  Development  and  Execution  Process  Model 
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Step  1:  Define  Federation  Objectives 

The  purpose  of  step  1  of  the  EEDEP  is  to  define  and  document  a  set  of  needs  that  are  to 
be  addressed  through  the  development  and  execution  of  an  HEA  federation  and  to  transform 
these  needs  into  a  more  detailed  list  of  specific  federation  objectives. 

Eigure  3-2  illustrates  the  key  activities  in  this  step  of  the  EEDEP.  In  this  diagram  (and 
all  subsequent  diagrams  in  this  section),  each  individual  activity  is  labeled  by  a  number 
designation  (X.Y)  to  show  traceability  between  the  activity  and  the  step  in  the  six-step  process  to 
which  the  activity  is  associated  (X).  The  activity  number  (Y)  in  these  diagrams  is  intended  only 
as  an  identifier  and  does  not  prescribe  a  particular  ordering.  The  subsections  that  follow  describe 
each  of  these  activities. 


Figure  3-2.  Define  Federation  Objectives  (Step  1) 

Activity  1.1  Identify  Needs 

The  primary  purpose  of  this  activity  is  to  develop  a  clear  understanding  of  the  problem  to 
be  addressed  by  the  federation.  The  needs  statement  may  vary  widely  in  terms  of  scope  and 
degree  of  formalization.  It  should  include,  at  a  minimum,  high-level  descriptions  of  critical 
systems  of  interest,  coarse  indications  of  fidelity  and  required  behaviors  for  simulated  entities, 
key  events  that  must  be  represented  in  the  federation  scenario,  and  output  data  requirements.  In 
addition,  the  needs  statement  should  indicate  the  resources  that  will  be  available  to  support  the 
federation  (e.g.,  funding,  personnel,  tools,  facilities)  and  any  known  constraints  that  may  affect 
how  the  federation  is  developed  (e.g.,  due  dates,  security  requirements).  In  general,  the  needs 
statement  should  include  as  much  detail  and  specific  information  as  is  possible  at  this  early  stage 
of  development. 

An  explicit  and  unambiguous  statement  of  federation  needs  is  critical  to  achieving  clear 
communication  of  intent  among  the  developers  of  the  federation.  Failure  to  establish  a  common 
understanding  of  the  required  product  can  result  in  costly  rework  in  later  stages  of  the  federation 
development  process. 
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Activity  1.2  Develop  Objectives 

The  purpose  of  this  activity  is  to  refine  the  needs  statement  into  a  more  detailed  set  of 
specific  objectives  for  the  federation.  The  federation  objectives  statement  is  intended  as  a 
foundation  for  generating  federation  requirements,  i.e.,  translating  high-level  user/sponsor 
expectations  into  more  concrete,  measurable  federation  goals.  This  activity  requires  close 
collaboration  between  the  federation  user/sponsor  and  the  federation  development  team  to  ensure 
that  the  resulting  objectives  are  consistent  with  the  stated  needs.  Examples  of  the  types  of 
information  that  might  be  documented  as  a  result  of  this  activity  would  include  the  following: 

•  A  prioritized  list  of  measurable  objectives  for  the  federation 

•  A  high-level  description  of  key  federation  characteristics  (repeatability,  portability,  time 
management  approach,  etc.) 

•  A  federation  development  plan  showing  an  approximate  schedule  and  major  milestones 

•  Estimates  of  needed  equipment,  facilities,  and  data 

•  Operational  context  constraints  or  preferences,  including  friendly/threat/civilian  Order  of 
Battle,  geographical  regions,  environmental  conditions,  and  tactics 

•  Identification  of  security  needs,  including  probable  security  level  and  possible  designated 
approval  authority  (or  authorities,  if  a  single  individual  is  not  possible) 

•  A  configuration  management  plan 

•  Initial  planning  documents  (e.g.,  VV&A,  test,  security) 

Early  assessments  of  federation  feasibility  and  risk  should  also  be  performed  as  part  of 
this  activity.  In  particular,  certain  objectives  may  not  be  achievable  given  practical  constraints 
(such  as  cost,  schedule,  availability  of  personnel  or  facilities)  or  even  limitations  on  the  state-of- 
the-art  of  needed  technology.  Early  identification  of  such  issues  and  consideration  of  these 
limitations  and  constraints  in  the  Eederation  Objectives  Statement  will  set  appropriate 
expectations  for  the  federation  development  effort. 

Einally,  the  issue  of  tool  selection  to  support  scenario  development,  conceptual  analysis, 
VV&A  and  test  activities,  and  configuration  management  should  be  addressed  before  the 
Develop  Objectives  activity  is  concluded.  These  decisions  are  made  by  the  federation 
development  team  on  the  basis  of  tool  availability,  cost,  applicability  to  the  given  application, 
and  the  personal  preferences  of  the  participants.  The  ability  of  a  given  set  of  tools  to  exchange 
federation  data  is  also  an  important  consideration. 
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Step  2:  Develop  Federation  Conceptual  Model 

The  purpose  of  this  step  of  the  EEDEP  is  to  develop  an  appropriate  representation  of  the 
real  world  domain  that  applies  to  the  federation  problem  space  and  to  develop  the  federation 
scenario.  It  is  also  in  this  step  that  federation  objectives  are  transformed  into  a  set  of  highly 
specific  federation  requirements  that  will  be  used  as  success  criteria  during  federation  testing. 
Eigure  3-3  illustrates  the  key  activities  in  this  step  of  the  EEDEP.  The  subsections  that  follow 
describe  each  of  these  activities  in  detail. 


Figure  3-3.  Develop  Federation  Conceptual  Model  (Step  2) 

Activity  2.1  Develop  Scenario 

The  purpose  of  this  activity  is  to  develop  a  functional  specification  of  the  federation 
scenario.  The  primary  input  to  this  activity  is  the  operational  context  constraints  specified  in  the 
objectives  statement  (step  1),  although  existing  scenario  databases  may  also  provide  a  reusable 
starting  point  for  scenario  development.  A  federation  scenario  includes  the  types  and  numbers  of 
major  entities  that  must  be  represented  by  the  federation,  a  functional  description  of  the 
capabilities,  behavior,  and  relationships  between  these  major  entities  over  time,  and  a 
specification  of  relevant  environmental  conditions  that  impact  or  are  impacted  by  entities  in  the 
federation.  Initial  conditions  (e.g.,  force  laydowns),  termination  conditions,  and  specific 
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geographic  regions  should  also  be  provided.  Multiple  scenarios  may  be  developed  during  this 
step,  depending  on  the  needs  of  the  federation.  A  single  scenario  may  also  support  multiple 
vignettes,  each  representing  a  temporally  ordered  set  of  events  and  behaviors.  The  product  of 
this  activity  is  a  federation  scenario,  which  provides  a  bounding  mechanism  for  conceptual 
modeling  activities. 

The  presentation  style  used  during  scenario  construction  is  at  the  discretion  of  the 
federation  developers.  Textual  scenario  descriptions,  event-trace  diagrams,  and  graphical 
illustrations  of  force  laydowns  and  communication  paths  all  represent  effective  means  of 
conveying  scenario  information.  Graphical  scenario  development  tools  can  generally  be 
configured  to  produce  any  of  these  presentation  forms.  Reuse  of  existing  scenario  databases  may 
also  facilitate  the  Scenario  Development  activity. 

Activity  2.2  Perform  Conceptual  Analysis 

During  the  Conceptual  Analysis  activity,  the  federation  development  team  produces  a 
conceptual  representation  of  the  intended  problem  space  based  on  their  interpretation  of  user 
needs,  federation  objectives,  and  the  defined  environment.  The  product  resulting  from  this 
activity  is  known  as  a  federation  conceptual  model  (see  Eigure  3-3).  The  federation  conceptual 
model  provides  an  implementation-independent  representation  that  serves  as  a  vehicle  for 
transforming  objectives  into  functional  and  behavioral  capabilities;  the  model  also  provides  a 
crucial  traceability  link  between  the  federation  objectives  and  the  design  implementation.  This 
model  can  be  used  as  the  structural  basis  for  many  federation  design  and  development  activities 
(including  scenario  development)  and  can  highlight  correctable  problems  early  in  the  federation 
development  process  when  properly  validated. 

The  federation  conceptual  model  is  a  description  of  the  entities  and  actions  that  need  to 
be  included  in  the  federation  in  order  to  achieve  all  federation  objectives.  These  entities  and 
actions  are  described  without  any  reference  to  the  specific  simulations  that  will  be  used  in  the 
federation. 

Erom  the  perspective  of  Object-Oriented  (00)  software  system  designers,  the  federation 
conceptual  model  is  comparable  to  the  notion  of  a  traditional  object  model.  That  is,  the  focus  of 
federation  conceptual  model  development  is  to  identify  federation  objects,  to  identify  static  and 
dynamic  relationships  between  object  classes,  and  to  identify  the  behavioral  and  transformational 
(algorithmic)  aspects  of  each  class  of  object.  Static  relationships  can  be  expressed  as  ordinary 
associations  or  as  more  specific  types  of  associations  such  as  generalizations  (“is-a” 
relationships)  or  aggregations  (“part- whole”  relationships).  Dynamic  relationships  should 
include  (if  appropriate)  the  specification  of  temporally  ordered  sequences  of  object  interactions 
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with  associated  trigger  conditions.  Object  characteristics  (attributes)  and  interaction  descriptors 
(parameters)  may  also  be  identified  to  the  extent  possible  at  this  early  stage  of  design.  While 
other  conceptual  modeling  approaches  may  be  used  that  are  less  object-oriented  in  nature,  it  is 
important  that  the  real  world  domain  to  be  represented  in  the  federation  is  expressed  in  terms  of 
objects  and  object  interactions. 

Many  commercial  software  tools  are  readily  available  that  can  capture  most  aspects  of  the 
federation  conceptual  model.  Once  the  federation  conceptual  model  is  completed,  it  needs  to  be 
carefully  evaluated  before  the  next  step  (Eederation  Design)  is  begun,  including  a  review  of  key 
processes  and  events  by  the  user/sponsor  to  ensure  the  adequacy  of  the  domain  representation. 
Revisions  to  the  original  federation  objectives  may  be  defined  and  implemented  as  a  result  of  this 
feedback. 

Activity  2.3  Develop  Federation  Requirements 

As  the  federation  conceptual  model  is  developed,  it  will  lead  to  the  definition  of  a  set  of 
detailed  federation  requirements.  These  requirements,  based  on  the  original  federation  objectives 
(step  1),  should  be  directly  testable  and  should  provide  the  implementation  level  guidance  needed 
to  design  and  develop  the  federation.  The  federation  requirements  should  also  explicitly  address 
the  issue  of  fidelity,  so  that  fidelity  requirements  can  be  considered  during  selection  of  federation 
participants.  In  addition,  any  programmatic  or  technical  constraints  on  the  federation  should  be 
refined  and  described  to  the  degree  of  detail  necessary  to  guide  federation  implementation. 

Step  3:  Design  Federation 

The  purpose  of  this  step  of  the  EEDEP  is  to  identify,  evaluate,  and  select  all  federation 
participants  (federates),  allocate  required  functionality  to  those  federates,  and  develop  a  detailed 
plan  for  federation  development  and  implementation.  Eigure  3-4  illustrates  the  key  activities  in 
this  step  of  the  EEDEP.  The  subsections  that  follow  describe  each  of  these  activities  in  detail. 

Activity  3.1  Select  Federates 

The  purpose  of  this  activity  is  to  determine  the  suitability  of  individual  simulation 
systems  to  become  members  of  the  federation.  This  is  normally  driven  by  the  perceived  ability  of 
potential  federation  members  to  represent  objects,  activities,  and  interactions  in  the  federation 
conceptual  model.  In  some  instances,  federation  membership  may  be  at  least  partially 
predetermined  by  the  federation  user/sponsor.  Other  managerial  constraints  (e.g.,  availability. 
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Federation 


Figure  3-4.  Design  Federation  (Step  3) 


security,  facilities)  and  technical  constraints  (e.g.,  VV&A  status,  portability)  may  also  influence 
the  selection  of  federation  members.  The  searching  and  browsing  features  provided  by  the  HEA 
Object  Model  Eibrary  (OME)  may  be  used  to  search  electronic  libraries  of  Simulation  Object 
Models  (SOMs)  for  candidate  simulations,  keyed  to  critical  objects  and  interactions  of  interest. 
To  support  final  federate  selection  decisions,  additional  information  resources  (such  as  design 
and  compliance  documents)  are  generally  necessary  to  fully  understand  internal  simulation 
representations  of  required  behaviors/activities  and  other  practical  aspects  of  federate  utilization. 


Activity  3.2  Allocate  Functionality 

Once  all  federates  have  been  identified,  the  next  major  activity  is  to  allocate  the 
responsibility  to  represent  the  entities  and  actions  in  the  federation  conceptual  model  to  the 
federates.  This  activity  will  allow  for  an  assessment  of  whether  the  set  of  selected  federates 
provides  the  full  set  of  required  functionality  or  whether  one  or  more  of  the  federates  will  need  to 
be  enhanced  to  meet  the  federation  requirements. 

As  agreements  on  assigned  responsibilities  are  negotiated,  various  federation  design 
trade-off  investigations  may  be  conducted  as  appropriate.  Many  of  these  investigations  can  be 
considered  to  be  early  execution  planning  and  may  include  technical  issues  such  as  time 
management,  federation  management,  runtime  performance,  and  potential  implementation 
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approaches.  The  major  inputs  to  this  activity  include  the  federation  requirements,  the  federation 
scenario,  and  the  federation  conceptual  model  (see  Eigure  3-4).  High-level  federation  design 
strategies,  including  modeling  approaches  and/or  tool  selection,  may  be  revisited  and 
renegotiated  at  this  time  based  on  inputs  from  the  federates.  When  the  federation  represents  a 
modification  or  extension  to  a  previous  federation,  new  federates  must  be  made  cognizant  of  all 
previously  negotiated  agreements  within  that  earlier  federation  and  given  the  opportunity  to 
revisit  pertinent  technical  issues.  Eor  secure  federations,  efforts  associated  with  maintaining  a 
secure  posture  during  the  federation  execution  can  begin  at  this  time.  A  security  point  of  contact 
and/or  federate  security  representatives  must  be  designated.  These  roles  may  be  part  time, 
depending  on  the  size  and  complexity  of  the  execution.  The  initial  security  risk  assessment  and 
concept  of  operations  may  be  refined  at  this  time  to  clarify  the  security  level  and  mode  of 
operation. 

Activity  3.3  Prepare  Plan 

Another  major  activity  in  step  3  (Eederation  Design)  is  to  develop  a  coordinated  plan  to 
guide  the  development,  test,  and  execution  of  the  federation.  This  requires  close  collaboration 
among  all  federation  participants  to  ensure  a  common  understanding  of  federation  goals  and 
requirements  and  also  to  identify  (and  agree  to)  appropriate  methodologies  and  procedures  based 
on  recognized  systems  engineering  principles.  The  initial  planning  documents  prepared  during 
development  of  the  federation  objectives  provides  the  basis  for  this  activity  (see  Eigure  3-4).  The 
plan  should  include  the  specific  tasks  and  milestones  for  each  federate,  along  with  proposed  dates 
for  completion  of  each  task. 

The  plan  may  also  identify  the  software  tools  that  will  be  used  to  support  the  remaining 
life  cycle  of  the  federation  (e.g.,  RTI  version,  federation  runtime  tools,  CASE,  configuration 
management,  VV&A,  testing).  Eor  federations  with  stochastic  factors,  the  plan  should  include  an 
experimental  design  to  control  variability  (e.g.,  variance  reduction  techniques)  and  must  include 
determining  the  number  of  replications  of  the  execution  that  are  required  to  achieve  desired 
confidence  intervals.  These  agreements,  along  with  a  detailed  work  plan,  must  be  documented 
for  later  reference  and  possible  reuse  in  other  federations. 

Step  4:  Develop  Federation 

The  purpose  of  this  step  is  to  develop  the  EOM,  modify  federates  if  necessary,  and 
prepare  the  federation  for  integration  and  test  (database  development,  security  procedure 
implementation,  etc.).  Eigure  3-5  illustrates  the  key  activities  in  this  phase  of  the  EEDEP.  The 
subsections  that  follow  describe  each  of  these  activities  in  detail. 
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Figure  3-5.  Develop  Federation  (Step  4) 


Activity  4.1  Develop  FOM 

Using  the  federates  identified  to  meet  federation  requirements  and  the  allocation  of 
responsibilities  for  representation  of  entities  and  actions  in  the  federation  conceptual  model 
across  these  federates,  the  FOM  is  developed  to  support  the  data  exchanges  required  among  the 
federates  to  meet  the  federation  objectives.  Several  different  fundamental  approaches  can  be 
taken  to  FOM  development,  all  of  which  have  unique  advantages  depending  on  the  particular 
situation.  These  approaches  include  the  following: 

•  Construct  the  FOM  from  the  “bottom  up,”  using  the  Object  Model  Data  Dictionary  (OMDD), 
the  federation  scenario,  and  the  federation  conceptual  model. 

•  Merge  together  the  SOMs  of  all  participating  federates,  removing  those  aspects  of  the  SOMs 
that  do  not  apply  to  the  domain  of  interest. 

•  Begin  with  the  SOM  that  most  closely  aligns  with  the  desired  FOM,  remove  those  aspects  of 
the  SOM  that  do  not  apply  to  the  domain  of  interest,  and  merge  in  elements  of  other  SOMs  to 
fully  represent  the  domain. 
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•  Begin  with  a  POM(s)  from  a  previous,  but  similar,  application.  Modify  and/or  augment  as 
required. 

•  Begin  with  a  POM  that  provides  a  common  frame  of  reference  to  a  given  user  community. 
Remove  elements  of  the  POM  that  are  not  required  for  the  application.  Modify  and/or 
augment  only  if  necessary. 

While  each  of  these  last  four  approaches  may  represent  a  somewhat  more  efficient  POM 
development  strategy  (relative  to  starting  entirely  from  scratch)  under  certain  circumstances,  all 
will  require  some  use  and  appropriate  tailoring  of  the  essential  activities  described  in  the  current 
HPA  Object  Model  (OM)  Development  Process  [ITC98].  A  summary  of  these  activities  is 
provided  in  Pigure  3-6.  Pederation  security  personnel  must  always  maintain  knowledge  of  any 
classified  information  associated  with  applicable  entries  in  each  federate’s  SOM  and  the 
implications  when  this  data  is  combined  into  a  single  POM. 

The  use  of  automated  tools  to  facilitate  the  object  model  development  process  is  strongly 
encouraged.  As  discussed  earlier,  the  HPA  OMP  provides  users  with  access  to  libraries  of 
reusable  object  models  that  can  be  used  either  as  a  starting  framework  or  as  individual  “piece 
parts”  for  a  new  POM.  In  addition.  Object  Model  Development  Tools  (OMDTs)  may  be  used  to 
modify  or  extend  an  existing  object  model  or  to  build  an  entirely  new  object  model  from  scratch. 
Other  OMDT  features  include  consistency  checking,  syntax  checking,  Pederation  Execution  Data 
(PED)  file  generation,  external  interfaces  to  commercial  object  model  development  tools,  and  an 
on-line  users  manual. 


OMT  Components 


Figure  3-6.  FOM  Development  Process 
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Activity  4.2  Establish  Federation  Agreements 

Although  the  POM  defines  and  documents  the  full  set  of  data  that  is  exchanged  among 
federates  to  achieve  federation  objectives,  there  are  other  types  of  agreements  that  must  be 
reached  among  the  federates  (prior  to  implementation)  that  are  not  necessarily  documented  in  the 
POM.  Such  agreements  are  necessary  to  establishing  a  fully  consistent,  interoperable  distributed 
simulation  environment.  Por  instance,  federation  members  must  use  the  federation  conceptual 
model  to  gain  an  understanding  and  agreement  on  the  behavior  of  all  federation  objects  and  how 
federation  objects  will  interact  with  each  other  during  the  execution.  Requirements  for  software 
modifications  to  selected  federates  may  be  identified  as  a  result  of  these  discussions;  such 
requirements  must  be  addressed  prior  to  federation  integration  activities.  Also,  agreements  must 
be  reached  as  to  the  databases  and  algorithms  that  must  be  common  (or  at  least  consistent)  across 
the  federation  to  guarantee  valid  interactions  (“fair  fights”)  among  all  federation  participants. 
Por  instance,  a  consistent  federation-wide  view  of  simulated  environmental  features  and 
phenomena  is  critical  in  order  for  objects  owned  by  different  federates  to  interact  and  behave  in  a 
realistic  fashion. 

Once  all  authoritative  data  sources  that  will  be  used  in  support  of  the  federation  have 
been  identified,  the  actual  data  stores  are  used  to  transition  the  functional  description  of  the 
scenario  (developed  in  step  2;  see  Pigure  3-3)  to  an  executable  scenario  instance  (or  set  of 
instances).  The  product  of  this  activity  permits  federation  testing  to  be  conducted  directly  within 
the  context  of  the  domain  of  interest  and  also  drives  the  execution  of  the  federation  later  in  the 
PEDEP. 

Pinally,  certain  operational  issues  must  be  addressed  and  resolved  among  the  members  of 
the  federation.  Por  instance,  agreements  on  federation  initialization  procedures,  synchronization 
points,  and  save/restore  policies  are  all  necessary  to  ensure  proper  operation  of  the  federation.  In 
addition,  federates  should  revisit  the  federation  requirements  at  this  time  to  ensure  a  common 
understanding  as  to  the  data  that  must  be  gathered  during  execution  to  produce  user/sponsor- 
specified  outputs  and  the  strategy  that  will  be  used  to  collect  that  data. 

Activity  4.3  Implement  Federate  Modifications 

The  purpose  of  this  activity  is  to  implement  whatever  modifications  are  necessary  to  the 
federates  to  ensure  that  they  can  represent  assigned  objects  and  associated  behaviors  as  described 
in  the  federation  conceptual  model  (step  2),  produce  and  exchange  federation  data  with  other 
federates  as  defined  by  the  POM,  and  abide  by  the  established  federation  agreements.  This  may 
require  internal  modifications  to  the  federate  to  support  assigned  domain  elements,  or  it  may 
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require  modifications  or  extensions  to  the  federate’s  HEA  interface  to  support  new  EOM  data 
structures  or  HEA  services  that  were  not  supported  in  the  past.  In  some  cases  (for  non-HEA 
compliant  federates)  it  may  even  be  necessary  to  develop  an  HEA  interface  for  the  federate.  In 
this  situation,  the  federate  must  consider  both  the  resource  (e.g.,  time,  cost)  constraints  of  the 
immediate  application  as  well  as  longer-term  reuse  issues  in  deciding  the  best  overall  strategy  for 
completing  the  federate  interface. 

Step  5:  Integrate  and  Test  Federation 

The  purpose  of  this  step  of  the  EEDEP  is  to  plan  the  federation  execution,  establish  all 
required  interconnectivity  between  federates,  and  test  the  federation  prior  to  execution.  Eigure  3- 
7  illustrates  the  key  activities  in  this  step  of  the  EEDEP.  The  subsections  that  follow  describe 
each  of  these  activities. 


Figure  3-7.  Integrate  and  Test  Federation  (Step  5) 

Activity  5.1  Plan  Execution 

The  purpose  of  this  activity  is  to  define  and  develop  the  full  set  of  information  required  to 
support  an  HEA  federation  execution.  In  addition  to  refining  test  and  VV&A  plans,  the  main 
activity  in  this  step  is  to  document  the  template  of  information  described  in  the  Eederation 
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Execution  Planners  Workbook  (EEPW).  This  workbook  provides  a  common,  structured 
mechanism  for  describing  the  performance  requirements  of  the  federation  and  for  defining  other 
essential  characteristics  of  HEA  federations,  including  federate  performance,  host  requirements, 
and  network  requirements.  Collectively,  the  tables  provided  in  this  workbook  define  all  of  the 
execution-specific  information  needed  by  a  federation  developer  to  test  and  operate  the 
federation.  The  completed  workbook,  taken  together  with  the  EOM  and  associated  EED  file, 
provides  the  necessary  foundation  to  transition  into  the  integration  and  testing  phase  of  federation 
development. 

An  additional  activity  in  this  step  for  secure  federations  is  to  develop  a  security  test  and 
evaluation  plan.  This  task  requires  reviewing  and  verifying  the  security  work  accomplished  thus 
far  in  the  federation  development  and  finalizing  the  technical  details  of  security  design,  such  as 
information  downgrading  rules,  formalized  practices,  etc.  This  plan  represents  an  important 
element  of  the  necessary  documentation  set  for  the  federation. 

Einally,  in  situations  in  which  federation  performance  is  an  especially  critical  issue,  it 
may  be  desirable  to  modify  the  RTI  Initialization  Data  (RID)  file  associated  with  the  specific  RTI 
implementation  being  used  in  the  federation.  Although  the  need  for  RID  file  modifications  will 
be  unnecessary  in  most  federations,  performance  enhancements  may  be  achievable  in  some 
circumstances. 

Activity  5.2  Integrate  Federation 

The  purpose  of  this  activity  is  to  bring  all  of  the  federation  participants  into  a  unifying 
operating  environment.  This  requires  that  all  federate  hardware  and  software  assets  are  properly 
installed  and  interconnected  in  a  configuration  that  can  satisfy  all  EOM  data  interchange 
requirements  and  federation  agreements.  The  federation  development  plan  specifies  the 
methodology  used  in  this  activity  for  federation  integration,  and  the  federation  scenario  instance 
provides  the  necessary  context  for  integration  activities. 

Eederation  integration  is  normally  performed  in  close  coordination  with  federation 
testing.  Iterative  “test-fix-test”  approaches  are  used  quite  extensively  in  practical  applications 
and  have  been  shown  to  be  quite  effective. 

Activity  5.3  Test  Federation 

The  purpose  of  this  activity  is  to  test  that  all  of  the  federation  participants  can  interoperate 
to  the  degree  required  to  achieve  federation  objectives.  Three  levels  of  testing  are  defined  for 
HEA  applications: 
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Federate  Testing:  In  this  activity,  each  federate  is  tested  to  ensure  that  the  federate  software 
correctly  implements  the  federation  requirements  as  documented  in  the  HEA  EOM,  EEPW,  and 
any  other  federation  operating  agreements. 

Integration  Testing:  In  this  activity,  the  federation  is  tested  as  an  integrated  whole  to  verify  a 
basic  level  of  interoperability.  This  testing  primarily  includes  observing  the  ability  of  the 
federates  to  interact  correctly  with  the  RTI  and  to  exchange  data  as  described  by  the  EOM. 

Federation  Testing:  In  this  activity,  the  ability  of  the  federation  to  interoperate  to  the  degree 
necessary  to  achieve  federation  objectives  is  tested.  This  includes  observing  the  ability  of 
federates  to  interact  according  to  the  defined  scenario  and  to  the  level  of  fidelity  required  for  the 
application.  This  activity  also  includes  security  certification  testing  if  required  for  the 
application. 

Procedures  for  conducting  federation  testing  must  be  agreed  upon  by  all  federation 
participants  and  documented  in  a  formal  test  plan.  Data  collection  plans  should  be  exercised 
during  the  testing  phase  to  ensure  that  the  data  needed  to  support  the  federation  objectives  is 
being  accurately  collected  and  stored.  The  HEA  Management  Object  Model  (MOM)  may  be 
used  during  integration/federation  testing  to  provide  useful  information  on  the  operation  of  the 
RTI,  individual  federates,  and  the  integrated  federation. 

The  desired  output  from  this  activity  is  a  set  of  testing  data  that,  once  evaluated,  indicates 
that  execution  of  the  federation  can  commence.  If  early  testing  data  uncovers  obstacles  to 
successful  federation  integration,  federate  or  federation  developers  must  take  corrective  actions. 
In  many  cases,  these  corrective  actions  simply  require  a  relatively  minor  software  fix  (or  series  of 
fixes)  or  minor  adjustment  to  the  EOM.  However,  testing  may  also  uncover  more  serious 
software  or  interoperability  problems.  In  these  cases,  options  may  need  to  be  identified,  with 
their  associated  cost  and  schedule  estimates  (including  security  and  VV&A  implications),  and 
should  be  discussed  with  the  federation  user/sponsor  before  corrective  action  is  taken. 

Einally,  whenever  a  federate  has  modified  its  HEA  interface  to  meet  federation 
requirements,  that  federate  should  be  tested  (or  retested)  for  compliance  to  the  HEA.  Although 
this  task  may  be  performed  at  this  time,  compliance  testing  may  also  be  performed  as  a  post¬ 
federation  activity. 

Step  6:  Execute  Federation  and  Prepare  Results 

The  purpose  of  this  step  of  the  EEDEP  is  to  execute  the  federation,  process  the  output  data  from 
the  federation  execution,  report  results,  and  archive  reusable  federation  products.  Eigure  3-8 
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illustrates  the  key  activities  in  this  step  of  the  EEDEP.  The  subsections  that  follow  describe  each 
of  these  activities. 


Figure  3-8.  Execute  Federation  and  Prepare  Results  (Step  6) 

Activity  6.1  Execute  Federation 

The  purpose  of  this  activity  is  to  exercise  all  federation  participants  as  an  integrated 
whole  to  generate  required  outputs  and  thus  achieve  stated  federation  objectives.  The  federation 
must  have  been  tested  successfully  before  this  activity  can  begin.  Besides  executing  the 
federation  in  a  coordinated  fashion  over  time,  this  activity  principally  includes  execution 
management  and  data  collection.  Execution  management  involves  controlling  and  monitoring 
the  execution  via  specialized  software  tools  (as  appropriate).  Execution  can  be  monitored  at  the 
hardware  level  (e.g.,  CPU  usage,  network  load),  or  software  operations  can  be  monitored  for 
individual  federates  or  across  the  full  federation.  Data  collection  is  focused  on  assembling  the 
desired  set  of  outputs  and  on  collecting  whatever  additional  supporting  data  is  required  to  assess 
the  validity  of  the  federation  execution.  In  some  cases,  data  is  also  collected  to  support  replays  of 
the  federation  execution  (i.e.,  “playbacks”).  Essential  federation  data  may  be  collected  via 
databases  in  the  federates  themselves  or  can  be  collected  via  specialized  data  collection  tools 
directly  interfaced  to  the  RTI.  The  particular  strategy  for  data  collection  in  any  particular 
federation  is  entirely  at  the  discretion  of  the  federation  development  team. 
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Eor  secure  federations,  strict  attention  must  be  given  to  maintaining  the  security  posture 
of  the  federation  during  execution.  A  clear  concept  of  operations,  properly  trained  security 
personnel,  and  strict  configuration  management  will  all  facilitate  this  process.  It  is  important  to 
remember  that  authorization  to  operate  (accreditation)  is  usually  granted  for  a  specific 
configuration  of  federates.  Any  change  to  the  federates  or  federation  composition  will  certainly 
require  a  security  review  and  may  require  some  or  all  of  the  security  certification  tests  to  be 
redone. 

Activity  6.2  Process  Output 

The  purpose  of  this  activity  is  to  post-process  (as  necessary)  the  output  collected  during 
the  federation  execution.  Such  post-processing  normally  requires  the  application  of  appropriate 
statistical  measures  and  other  data  reduction  methods  to  transform  raw  data  into  derived  results. 
Commercial  or  government  off-the-shelf  (COTS/GOTS)  statistical  analysis  tools  and  other  post¬ 
processing  tools  are  often  applicable  here. 

Activity  6.3  Prepare  Results 

This  activity  is  composed  of  two  main  tasks.  In  the  first  task,  the  derived  results  from  the 
previous  activity  are  evaluated  to  determine  if  all  federation  objectives  have  been  met.  This 
requires  a  retracing  of  execution  results  to  the  measurable  set  of  federation  requirements 
originally  generated  during  Conceptual  Analysis  (step  2)  (and  refined  in  subsequent  steps).  In 
the  vast  majority  of  cases,  any  impediments  to  fully  satisfying  federation  requirements  have 
already  been  identified  and  resolved  much  earlier  during  the  federation  development  and 
integration  phases.  Thus,  for  well-designed  federations,  this  task  is  merely  a  final  check.  In 
those  rare  cases  in  which  certain  federation  objectives  have  not  been  fully  met  at  this  late  stage  of 
the  overall  process,  corrective  actions  must  be  identified  and  implemented.  This  may  necessitate 
revisiting  previous  steps  of  the  EEDEP  and  regenerating  federation  results. 

The  second  task  in  this  activity,  assuming  all  federation  objectives  have  been  achieved,  is 
to  store  all  reusable  federation  products  in  an  appropriate  archive  and,  if  appropriate,  make  them 
available  through  systems  such  as  the  Modeling  and  Simulation  Resource  Repository  (MSRR). 
At  a  minimum,  this  would  include  storing  the  EOM  and  any  modifications  to  the  SOMs  of 
federation  participants  in  the  OME.  However,  there  are  several  other  federation  products  that 
may  also  be  reusable,  such  as  new  OMDD  entries,  the  federation  scenario,  and  the  federation 
conceptual  model.  In  fact,  it  may  be  advantageous  in  some  instances  to  capture  the  full  set  of 
federation  products  required  to  reproduce  the  federation  execution.  Determination  of  which 
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federation  products  have  potential  for  reuse  in  future  applications  is  at  the  discretion  of  the 
federation  development  team. 
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4.  CONCLUSION 


This  document  has  provided  a  view  of  the  federation  development  and  execution  process. 
Currently,  this  model  represents  the  best  practices  available  to  the  HEA  community.  The  EEDEP 
is  an  easily  tailored  model  and  is  offered  as  guidance  to  HEA  federation  developers.  As 
additional  experience  is  accrued  in  building  HEA  applications,  the  EEDEP  will  leverage  this 
knowledge  and  evolve  accordingly. 

In  the  longer  term,  the  EEDEP  is  expected  to  serve  as  a  framework  for  the  development 
of  alternative,  more  detailed  views  of  the  federation  development  process  that  may  better  satisfy 
the  needs  of  specific  communities.  Such  views  can  provide  implementation  level  guidance  to 
“hands-on”  federation  builders  without  the  need  to  interpret  and  customize  the  more  generalized 
EEDEP  activity  descriptions  to  a  particular  domain.  Eederation  developers  are  encouraged  to 
perform  these  types  of  adaptations  whenever  appropriate. 
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COTS 

Commercial  Off-the-Shelf 

DED 

Data  Plow  Diagram 

DMSO 

Defense  Modeling  and  Simulation  Office 

DoD 

Department  of  Defense 

EED 

Pederation  Execution  Data 

EEDEP 

Pederation  Development  and  Execution  Process 

EEPW 

Pederation  Execution  Planners  Workbook 

POM 

Pederation  Object  Model 

GOTS 

Government  Off-the-Shelf 

HEA 

High  Eevel  Architecture 

M&S 

Modeling  &  Simulation 

MOM 

Management  Object  Model 

MSRR 

Modeling  and  Simulation  Resource  Repository 

OM 

Object  Model 

OMDD 

Object  Model  Data  Dictionary 

OMDT 

Object  Model  Development  Tool 

OME 

Object  Model  Eibrary 

OMT 

Object  Model  Template 

00 

Object  Oriented 

RID 

RTI  Initialization  Data 

RTI 

Runtime  Infrastructure 

SOM 

Simulation  Object  Model 

VV&A 

Verification,  Validation,  and  Accreditation 
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